| Back to Index |
Apologies, I don't have many interesting pictures this week!
I'd give myself a solid C- this week. If my goal was to modify some c code (provided here) by Rob Hart) so that it worked on my board, then I guess I met my goal, but certainly didn't exceed it. I perused the ATTiny 44 data 'sheet' (read: novel), and gained a basic macro understanding of all the tiny elements working together in a surprisingly small, powerful, and efficient chip. I read the first couple chapters of Make: AVR Programming, and got a basic understanding of the concepts of coding, compiling, and flashing to my board. I learned that Boolean logic is probably something I should become more familiar with, as that's how coding in c seems to operate. And at some point soon, I'll sit down with a c tutorial and learn to speak the language.
Practically speaking, I learned some basic things about how to specify which pins serve which purposes:
- For the Atmel ATTiny 44, when you want a pin to serve as an input, use PORTA or PORTB, depending on which register (A or B) your pin is connected.
- When you want a pin to serve as an output, use DDRA or DDRB (for register A or B).
- Pins are specificed in c using the following format: 0b00000000. Change a 0 to a 1 to indicate which pin, leaving that number of 0s to the right of the 1. For example, if you wanted to set an LED output on PA2 (Register A, Pin 2), you would say DDRA=0b00000100.
With this knowledge in mind, I modified Rob's code so that the specified pins in the code matched my board. Using Brian Plancher's computer and programmer (for reasons that will become clear below), I uploaded the code to my hello board, and was rewarded by a glowing green light when I press the button. Technically speaking, success! My code worked.
We've now reached the end of what I can authoritatively speak about. Most of my time in the shop was spent wrestling with my programmer (from week 2) and my arguably poor decision to invest in personal computers that operate on Windows. I should figure out how to boot Ubuntu or Linux on them, but I haven't done that yet. Instead, I followed this tutorial to put the GNU AVR toolchain and necessary drivers on my computer. I got all the way to "Install Drivers for your Programmer" when my headaches began. Zadig refused to recognize my programmer when I plugged it in. I wrestled with that for a while, then, just for ha-has, I plugged Rob's programmer in to my computer. It recognized it as a FabISP, telling me the problem may not be with my computer. I then set out on a baffling journey to figure out what was wrong with my programmer.
My programmer definitively worked at the end of week 2. It was programmed successfully, and programmed another programmer at the time as well. So Tiffany Cheng, one of the Harvard TAs, showed me how to check the board with a multi-meter, and found that everything that should be getting power was, and everything that shouldn't be getting power wasn't.
It's at this point that my memory of events gets a little muddled. I was in a state of at least mild confusion, and events transpired such that I'm not sure what went wrong and what went right, or when, or why. It's posible I'm not accurately describing them here. As we couldn't find anything obviously wrong with the board, Tiffany suggested changing the ATTiny44 chip itself, which I did. With a new chip, it needed programming again. (Add back in that solder bridge necessary to make it programmable!) It did well through the 'make clean' and 'make hex' steps, but encountered a "does not recognize USB device" error (or something to that effect) on the 'make fuse' step. Tiffany said this indicates an issue with the clock, and suggested I replace my resonator, which I did. Same error came up.
Rob and I checked the solder joints on my board, and found a USB pin that wasn't adequately secured. We reflowed every other joint on the board, just to be safe, and were able to program my programmer with the AVRISP2 on a Mac. After a confusing series of events involving multiple computers (both Mac and Windows), and multiple programmers (both AVRISP2 and usbtiny), it became clear that my programmer worked on Mac computers, but not on Windows. I speculated that it was because I had used the all-in-one resonator, rather than the crystal-with-two-separate-resistors (which Rob's board has), as one is more accurate than the other.
I guessed that Windows just had lower tolerances for timing variation. I resigned myself to making a new programmer with the crystal-and-resistors, so I could have one that could successfully communicate with my Windows machines. I set that board milling, and contemplated where I had gone wrong with my life.
So. My hello LED board had been successfully programmed, which meant I knew my code worked. My Windows computer recognized Rob's ISP. So I decided to try programming my Hello board using my computer, just so I could get a sense of the workflow. I *think* I did it right, as the LED lit up when I pressed my button, but I couldn't be sure that wasn't just the earlier round of programming still working.
I'm pretty sure this is the correct series of commands to put into a terminal:
"avrdude -c usbtiny -p t44" just checks to make sure everything is talking to everything it should be.
"make -f file_name.make" creates the hex files from the .c and make files.
"avrdude -c usbtiny -p t44 -U flash:w:file_name.c.hex" actually flashes said hex code to the programmee.
Just for ha-has (again), I swapped out Rob's ISP for my original one, and re-ran the programming protocol. Somehow it worked. I am now very confused. I don't know why it wasn't working, and I'm definitely not sure what I did to change its mind.
The only way for me to know for sure whether everything worked would be to try and upload a different code, one that makes the LED blink, or fade in and out. However, I'm not experienced enough with c yet to figure out how to program those functionalities, so ... I guess I finished the work for the week? But I should definitely do a tutorial or two soon. As my potential final project involves many LEDs (and other lighting outputs) fading on to various levels of brightness in a specific sequence, I should probably figure out how to do more than just turn an LED on. Unfortunately, most of my worktime this week was eaten up trying to fix a programmer that may or may not have been broken.
